When providing Asynchronous Transfer Mode (ATM) access on a communication switch or router capable of sophisticated Layer 3 communication traffic management, as is often the case in communication systems, it is generally desirable to allow outgoing customer communication traffic to be subject to communication traffic management at both Layer 3, typically Internet Protocol (IP), and Layer 2 (ATM). In other words, a service provider may wish to shape or rate limit different classes of IP traffic separately, and then shape the aggregate flow in conformance with an ATM traffic descriptor.
However, ATM traffic management is typically provided through specialized hardware that is also responsible for cell segmentation and reassembly, while IP traffic management may use the same hardware as is used for other access technologies at a switch or router. Relatively generic and costly hardware which supports various technologies such as IP may therefore be provided in multiple circuit card slots of a switch or router. Any of a variety of types of less costly medium- or protocol-specific access technology modules such as line cards are then connected to the generic hardware to provide an interface to a lower layer protocol for each circuit card slot. The same routing hardware may thus be used with different access technology modules.
In advanced communication switches or routers, communication traffic management at both Layer 3 (L3 ), to enable different communication traffic handling for different Differentiated Service Code Point (DSCP) codepoints for instance, and Layer 2 (L2 ), such as shaping in conformance with an ATM traffic descriptor, may be achieved through the use of specialized hardware that combines L3 and L2 communication traffic management in either a single communication device or a small number of devices that were designed to work together.
Hardware hierarchical ATM traffic management devices, for example, support multiple levels of hardware scheduling decisions that first decide whether a given ATM Virtual Circuit (VC) should be allowed to transmit, typically based on a weighted-round robin for scheduled ATM traffic or a slot-based shaping wheel for shaped ATM traffic, and then decide which L3 class-based queues constituting that VC should be allowed to transmit, based on strict priority of some classes over others, weighted round-robin or simple round-robin, or some combination of all three. If ATM traffic management is implemented in a separate communication device from the L3 traffic management, then there will typically be per-VC queuing in the ATM device and a per-VC backpressure mechanism from the ATM device to the L3 device to govern when L3 queues corresponding to a given VC should be allowed to transmit. In the latter scenario, the hardware backpressure mechanism must be able to support backpressure on thousands of contexts, which rules out standard buses such as System Packet Interface (SPI) 4.2, which is limited to 255 backpressure contexts.
When budget, time-to-market, or other constraints preclude the creation of specialized hardware, it may be necessary to combine L3 and L2 communication devices which were not designed to work together. Existing techniques for combined multi-layer communication traffic management do not deal with the problem of interconnecting separate traffic management devices. In this type of implementation, a particular traffic management device typically would not provide backpressure to a different traffic management device at all. Instead, each traffic management device discards communication traffic as queues exceed configured thresholds or if buffer pool exhaustion, indicative of high total queue occupancy, occurs. In the above example of L3 and ATM traffic management, the ATM traffic management device would discard communication traffic as its per-VC queues fill up. These discards are not L3 class-aware, with communication traffic of any particular L3 class just as likely to be discarded as communication traffic of any other L3 class, thereby effectively defeating the L3 traffic management.
Known communication traffic management techniques thus require that an ATM traffic management device either be integrated into or specially designed to operate with an L3 device in order to preserve any benefit of L3 traffic management. These techniques are therefore not suitable for adding ATM to existing communication equipment which already has an L3 traffic management device. This situation may arise during a product development cycle which, due to budget or time-to-market constraints, must use existing hardware devices.
Accordingly, there remains a need for a communication traffic management mechanism which allows the use of different traffic management devices to accomplish complex traffic management without using specialized hardware.